Subject: APPN MIB Stuff & Topo. Safe Store

From: [email-masked]
Date: Tue, 29 Aug 95 16:18:53 EDT

>>>Returning to the purpose of my original note to aiw-appn-mibs,
>>>I no longer have a problem with this object being added in the MIB.
>>>One question for the MIB, what value should be returned if the node
>>>does not periodically safe store, but instead does it at shutdown only,
>>>or perhaps also upon operator command?  From reading the VTAM doc, this
>>>is how they implemented safe store.

I think you're right about how VTAM implements safe store.  Regarding what
value they or similar implementations should return for this field, I'll let
the VTAM guru-dudes and/or MIB guru-dudes handle this.  (You know who you are.)

>>>Tim, one comment on the architecture pages:  since periodic safe
>>>store takes advantage of this as well as non-safe store, the comments on
>>>pages 7-31, 7-37, and 7-38 about when the condition (adjacent node is ahead
>>>of the local node in FRSN) occurs ought to be amended to reflect that this
>>>applies to periodic safe storing nodes as well non safe storing nodes.  The
>>>condition is not obvious and periodic safe store implementers could easily
>>>miss this and decide to skip this logic.

I agree....they are outdated and it is not obvious to anyone implementing
periodic safe store.  Someone in the APPN architecture area will amend them
appropriately.

Cheers,
Tim

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>
> Bob,
>
> Yes, there are products that perform a periodic safe store (i.e. every X TDUs)
> function.  There has been an architecture change made to TRS about a year or
> so ago that allows the scenario you describe to occur without causing the
> CP-CP session to come down.  Check out arch7945.psbin on the networking file
> server.  This change was originally meant to accomodate nonsafe storing nodes,
> but applies equally well to nodes that perform periodic safe store.
>
> I'll briefly describe what this change is.
> Using the scenario you described, if NNA receives a FRSN during the FRSN
> exchange (it only does this during the FRSN exchange), that is higher than
> its current FRSN, it increases its own FRSN to be one higher than that value.
> It also sets the LAST_FRSN_SENT field in its ANCB entry for the partner node
> to the value received.  So NNA won't bring down the CP-CP session, and also
> keeps NNB happy, because when NNA sends its first TDU to NNB, the FRSNs match
> what NNB expects from NNA.  Otherwise, NNB would also bring down that CP-CP
> session.  Arch7945 explains in a little more detail how this works.
>
> So the gist is that regarding the regulation of the "correctness" of FRSNs,
> nodes are forgiving when first connecting to other NNs (i.e. FRSN exchange),
> by accepting what their partner thinks was the last FRSN sent.  This
> accomodates nonsafe storing and periodic safe storing NNs.  After the topology
> exchange has occurred, any ensuing FRSN mismatches are either considered out
> of order TDUs or protocol violations, depending on the mismatch.
>
> Regards,
> Tim
>
>
> >
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > appnNodeNnSafeStoreFreq     OBJECT-TYPE
>
> Does any product really do an incremental safe store like this?
> It can cause CP-CP session failure upon restart very easily.
> Part of safe store is storing adjacent node last FRSN sent and received,
> so that you reduce TDU exchange when the node comes back up.
> Suppose NNA's safe store frequency is every 10 TDUs.  It does a safe store
> at FRSN 10, and goes down after sending a TDU with FRSN 15 to NNB.
> When NNA comes back up, on CP Capabilities exchange NNB will have claimed
> to have last received FRSN 15 from NNA, which puts it ahead of what NNA
> remembers sending.  NNA treats this as a protocol violation and will
> unbind CP-CP sessions with sense 08A00006.
> To make topology safe store work right, you have to either safe store
> on every TDU, or safe store on shutdown only.
> If someone can show me how incremental safe store can be made to reduce
> TDU flows effectively, I'm for keeping this, but unless that happens this
> should not be added to the MIB.
>
>
> Bob Clouston
>